Skip to content

The ledger shrank by nineteen, and one entry became countable - #2887

Merged
gHashTag merged 2 commits into
masterfrom
w734
Aug 29, 2026
Merged

The ledger shrank by nineteen, and one entry became countable#2887
gHashTag merged 2 commits into
masterfrom
w734

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

The corpus ratchet is red on master:

UNEXPECTED FAILURES: 1
  + specs/api/sdk_contract.t27 [parse-no-discard]
UNEXPECTED PASSES  : 19
  - specs/api/c_api_contract.t27 [parse] (fixed -- remove from the ledger)
  ... eighteen more ...

Nineteen improvements

All nineteen are [parse], and all nineteen are specs #2877 and #2882 unblocked — thirteen by reading # as a line comment, six by reading a hyphenated module name whole.

The ratchet fails on an improvement exactly as it fails on a regression, because an entry that starts passing must be removed. That is the design, not a defect in it.

The one failure is the same story from the other side

specs/api/sdk_contract.t27 appears in the passes list for [parse]. It now parses — and a spec that could not be parsed could not be measured for discard either. Not new loss; newly countable loss. The entry says so, and names #2882.

before after
ledger 169 151
max_entries 169 151
ratchet FAIL CLEAN

Two things --bless-expectations still does not do

Both set by hand here, same as in #2862:

  • it does not raise (or lower) max_entries, so a blessed ledger can still fail on the cap;
  • it writes unclassified: blessed by --bless-expectations as the reason for every entry it adds.

Refs #2882

The corpus ratchet was red on master:

    UNEXPECTED FAILURES: 1
      + specs/api/sdk_contract.t27 [parse-no-discard]
    UNEXPECTED PASSES  : 19
      - specs/api/c_api_contract.t27 [parse] (fixed -- remove from the ledger)
      ... eighteen more ...

All nineteen are `[parse]`, and all nineteen are specs #2877 and #2882
unblocked -- thirteen by reading `#` as a line comment and six by
reading a hyphenated module name whole. The ratchet fails on an
improvement exactly as it fails on a regression, because an entry that
starts passing must be removed, and that is the design.

The one new failure is the same story from the other side.
`specs/api/sdk_contract.t27` is in the passes list for `[parse]`: it now
parses, and a spec that could not be parsed could not be measured for
discard either. Not new loss -- newly countable loss. The entry says so.

    ledger        169 -> 151
    max_entries   169 -> 151
    RATCHET       FAIL -> CLEAN

`--bless-expectations` still does not raise `max_entries` and still
writes `unclassified: blessed by --bless-expectations` as the reason.
Both set by hand, as in #2862.

Refs #2882
@gHashTag
gHashTag enabled auto-merge (squash) August 29, 2026 21:17
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

1 similar comment
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-29 21:18:50 UTC

Summary

Status Count
Total Open PRs 8
PRs with Failing Checks 7
PRs with All Checks Green 1
READY 0
FAILING 7
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=f569da0c6c14 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-29 21:18:52 UTC

Summary

Status Count
Total Open PRs 8
PRs with Failing Checks 7
PRs with All Checks Green 1
READY 0
FAILING 7
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=f569da0c6c14 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit a9197e7 into master Aug 29, 2026
23 of 24 checks passed
gHashTag added a commit that referenced this pull request Aug 29, 2026
… improvements (#2888)

335: an audit ruled out the braceless `else` with "the corpus has 0 such
sites -- all 37 `} else <non-brace>` hits are paren-less `else if`".
There are four. They do not match that pattern because the `if` has no
braces either: `if (a >= b) return a else return b;` is one line, so
there is no `}` before the `else` to anchor on. A zero from a pattern
that cannot match the real spelling CLOSES the question, which makes the
defect harder to find again than if it had never been reported. Before
believing a zero, feed the pattern a case you know exists.

336: two ratchets went red in one hour and neither on a regression. The
Lean/Rust classifier reported four new disagreements because four specs
that could not be PARSED became parseable, so the classifier could
finally disagree with a theorem that had always been wrong. The corpus
ratchet reported 19 unexpected passes and 1 unexpected failure -- the
nineteen are that same unblocking, and the one failure is one of the
nineteen, now parsing and therefore now measurable for discard. A
down-only ratchet fails on an improvement exactly as on a regression,
and that is the design. The work is the same work, and the failure mode
is doing it without writing the reason down.

Refs #2883, #2887
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant